Until recently, wireless mobile terminals have been used basically for making voice calls. Standardised and well-established communication technologies and protocols are then utilised to communicate voice between fixed and/or mobile terminals using circuit-switched communication channels.
However, a multitude of new telephony services involving “multimedia” are now rapidly being developed, enabled by the introduction of new technologies allowing for notably higher transmission rates and increased network capacity. For example, GPRS (General Packet Radio Service) and WCDMA (Wideband Code Division Multiple Access) technologies are currently emerging for enabling wireless telephony services requiring a wide range of transmission rates and different protocols and media formats.
The trend today is also a move towards packet-switched networks and technologies providing more capacity and flexibility as compared to the traditional circuit-switched networks. Further, new sophisticated mobile terminals are also emerging on the market, equipped with functionality to handle the new services, including high resolution colour displays and various codecs (coders/decoders) e.g. for visual information.
Multimedia services typically involve transmission of encoded data representing text, documents, images, audio files and video files in a multitude of formats and combinations. The term “multimedia” will be used in this description as generally referring to any choice of media types, apart from ordinary voice dialogues and typically with some visual content, which is communicated by using the packet based IP (Internet Protocol) transport technology. Further, the term “media content” will be used to represent any such encoded data transferred when exercising multimedia services.
A network architecture called “IP Multimedia Subsystem” (IMS) has been developed by the 3rd Generation Partnership Project (3GPP) as an open standard, to give operators of access networks the ability to offer multimedia services in the packet domain. IMS is a platform for enabling services based on IP transport, involving immediate delivery of media content from one terminal to another, sometimes referred to as “instant messaging”. IMS is more or less independent of the access technology used, and is basically not restricted to any limited set of specific services.
A specification for handling sessions in IMS networks has been defined called “SIP” (Session Initiation Protocol, according to the standard IETF RFC 3261 et al). SIP is an application-layer control (signalling) protocol for creating, modifying and terminating sessions over a packet-switched logic. For example, a message called “INVITE” is defined in SIP to initiate a session during session set-up, when the terminals basically agree on which session parameters and codecs to use for the transfer of media content. The SIP standard is thus used by IMS systems to establish and control IP multimedia communications.
FIG. 1 illustrates schematically a basic network structure for providing multimedia services by means of an IMS service network. It should be noted that the figure is greatly simplified and only shows a selection of network nodes helpful to understand the context of the present invention. A calling mobile terminal A is connected to a first radio access network 100 and communicates with a called mobile terminal B connected to a second radio access network 102, in a communication session S involving one or more multimedia services. Alternatively, terminal A may communicate with a fixed terminal or computer or a content server delivering some multimedia content to the terminal, such as music, films, images or games.
An IMS network 104 is connected to the first radio access network 100 and handles the session with respect to terminal A, as initiated by its user. In fact, the IMS network 104 receives and processes any service requests or data from the user of terminal A. In this figure, a corresponding IMS network 106 handles the session on behalf of terminal B, and the two IMS networks 104 and 106 may be controlled by different operators. Similarly, the IMS network 106 receives and processes any service requests or data from the user of terminal B. Alternatively, terminals A and B may of course be connected to the same access network and/or belong to the same IMS network.
The illustrated session S is generally managed, using SIP signalling, by a node called S-CSCF (Serving Call Session Control Function) 108 assigned to terminal A in the IMS network 104, and the selected multimedia service is enabled and executed by an application server 110. Basically, the S-CSCF node 108 serves as a proxy for the application server 110 towards terminal, A and sends SIP messages from terminal A to the IMS network 106 of terminal B, as indicated by a dashed arrow towards block 106. Further, a main database element HSS (Home Subscriber Server) 112 stores subscriber and authentication data as well as service information, among other things, that the application server 110 can fetch for executing services for clients. The S-CSCF node 108 may also fetch information from the HSS 112 to determine which application server 110 to handle a service requested by terminal A, as determined by “triggers” in the HSS 112.
A node called I-CSCF (Interrogating Call Session Control Function) 114 is connected to other IMS networks, including network 106, and acts as a gateway for SIP messages from the other IMS networks. Thus, I-CSCF node 114 receives SIP messages from the IMS network 106 of terminal B, as indicated by another dashed arrow towards block 114. Another node called P-CSCF (Proxy Call Session Control Function) 116 acts as an entry point towards the IMS network 104 from any access network, such as network 100, and all signalling flows between clients and the IMS network 104 are routed through the P-CSCF 116.
Of course, the IMS network 104 contains numerous other nodes and functions, such as further S-CSCF nodes and application servers, which are not shown here for the sake of simplicity. Basically, the IMS network 106 comprises the same type of nodes as network 104. The shown application server 110 may be configured to provide one or more specific multimedia services to clients. The various specific functions of the S-CSCF, I-CSCF, P-CSCF nodes 108, 114, 116, and the application server 110 are not necessary to describe here further to understand the context of the present invention. Any of these network elements will generically be referred to as a “session manager” in the following description.
In this description, distinction is made between the term “immediate delivery”, referring to direct transfer of media content point-to-point from a sending terminal to a receiving terminal, and the term “deferred delivery” meaning that the sent media content is temporarily stored in an intermediate messaging service node, here generally called “messaging center”, for a period of time before it is finally delivered to the receiver. This method is sometimes also referred to as “store-and-forward” and is used in the well-known MMS (Multimedia Messaging Service) concept where the sent multimedia content is processed and stored in an MMS service node in the service network before delivery to the receiver. The processing of content data in MMS service nodes typically involves adaptation of the data to the capabilities of the receiving terminal by using well-established formats. In IMS networks, immediate delivery is practiced without any storage of communicated content in an intermediate messaging center.
However, IP multimedia communication will sometimes fail due to the inability of a terminal to receive content from another terminal. For example, the receiving terminal may not be currently registered with a multimedia service network. In another case, even when being registered, the terminal may not be capable of handling a specific required data format when lacking the necessary codec, or may not be able to receive data files that are too large due to lack of storage space, or may not support an application used by the other terminal, etc. In yet another case, the receiving terminal may simply not be available for communication, such as when powered off or out of radio coverage. It may also currently be connected to an access network that cannot submit communicated content to the terminal, e.g. due to a current lack of bandwidth or the network's incapability of handling circuit-switched and packet-switched communication simultaneously during an ongoing call.
A terminal unable to receive multimedia content for whatever reason, e.g. as exemplified above, will hereafter be referred to as “incompatible” for short. A “mainstream technology” has been developed allowing the terminating access network to convert the format of transmitted content into another format that the receiving terminal can handle, in the case of incompatibility. However, in the rapidly developing IP multimedia technology it is difficult for access networks to be up-to-date with the latest plethora of terminal capabilities for IP multimedia content, particularly visual content. It might also be possible for the sending terminal to convert the content “on the fly” into other formats that the receiving terminal hopefully can accept, and then try to send it again. However, this is a difficult task and far from all terminals have that capability.
If a first terminal generally tries to send IP multimedia content to an incompatible second terminal, e.g. by first sending an INVITE message according to the SIP standard, the second terminal will respond by sending some kind of error message, or not respond at all. In that case, the desired content cannot be conveyed to the incompatible second terminal and the first terminal will receive an error message from its service network. This situation will of course be perceived negatively by the terminal users, not being able to exchange multimedia content, as well as by network operators concerned being deprived of potential revenue.
Applicant's own European Patent Application EP 04445130.0 describes a solution where a sending entity checks the compatibility of a receiving terminal with respect to selected multimedia content to be transferred. If immediate delivery of the multimedia content is not possible due to incompatibility of the receiving terminal, the sending entity instead sends an MMS (message by deferred delivery including the selected content. However, this solution requires that specific functionality for converting the content into an MMS message is present in the sending entity.
Hence, it is desirable to overcome the problem of conveying IP multimedia content to incompatible terminals, without relying on the existing mainstream technology in access networks or on format conversion capabilities in terminals.